Unified channel management

ABSTRACT

A transaction for a customer is detected and transaction details are evaluated to obtain a federated customer profile that may span multiple channel communications. Policy conditions are evaluated to track and interact with the customer in a vendor-defined manner during the transaction. According to an embodiment, the transaction details, the customer profile, the tracked information, and other recorded interactions with the customer are accessible to the vendor for analysis, via a vendor interface.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.14/193,392, filed Feb. 28, 2014, which application and publication isincorporated herein by reference in its entirety.

BACKGROUND

Technology and automation has been aggressively adopted and integratedinto the business practices of many industries. Nowhere is this moreapparent than the travel and hospitality industries.

Customers can purchase airline tickets online and check-in for theirflights by using their mobile devices. They have the ability to check-into their hotel rooms and make restaurant reservations through kiosks.Automated messages can be pushed to inform customers what stall theirrental cards when their flight lands. Technology is positively impactinga passenger's journey and making their everyday processes easier.

Retailers quickly learned that the ability to reach their customers atthe right time and right location can be lucrative in marketingancillary or partner products and services. In fact, much of the traveland hospitality industry's growth in recent years is highly attributableto these industries marketing those ancillary products and services viamultiple technology channels consistently reach the consumer at theright time and place. This growing trend is leading travel suppliers toadopt best practices from the hospitality industry and driving them toact more like retailers.

One major interest of the travel and hospitality industries and theretail industry, generally, is the ability to track and reach theircustomers consistently across all available communication channels, somewhich are currently not accessible to those industries. For example, theairline industry still seeks to improve the technology and ability toreach and track consumers throughout their journey including pre andpost trip venues off airport.

Moreover, managing integrated inventory systems, payment systems,loyalty systems, marketing systems, and analytic systems is a difficultand an expensive endeavor for even the largest company to handle. Thisis further complicated with a travel supplier's geographic and off-lineconnectivity requirements. Leading to smaller start-up companies fromeven attempting to compete with the larger companies.

SUMMARY

In various embodiments, methods and system for unified channelmanagement are presented.

According to an embodiment, a method for unified channel management isprovided. Specifically, in an embodiment, a transaction is identifiedover a channel and a profile for a consumer associated with atransaction is federated over at least one other channel. Finally, anadvertisement is delivered during the transaction based on the federatedprofile.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an example architecture for practicing unifiedchannel management, according to an example embodiment.

FIG. 2 is a diagram of a method for unified channel management,according to an example embodiment.

FIG. 3 is a diagram of another method for unified channel management,according to an example embodiment.

FIG. 4 is a diagram of a unified channel management system, according toan example embodiment.

DETAILED DESCRIPTION

FIG. 1 is a diagram of an example architecture 100 for practicingunified channel management, according to an example embodiment. Thearchitecture 100 is shown schematically in greatly simplified form, withonly those components relevant to understanding of this embodiment beingillustrated. The various components are illustrated and the arrangementof the components is presented for purposes of illustration only. It isto be noted that other arrangements with more or less components arepossible without departing from the unified channel management presentedherein and below.

The techniques, methods, and system presented herein and below forunified channel management can be implemented in whole or in part inone, all, or some combination of the components shown with thearchitecture 100. The techniques and methods are programmed asexecutable instructions in memory and/or non-transitorycomputer-readable storage media and processed on one or more processorsassociated with the components (may also be referred to as “modules”).

In the embodiment for the architecture 100, the methods and system areimplemented as one or more hardware and software components of traveland hospitality systems or integrated with external travel andhospitality systems.

Specifically, the architecture 100 permits a consumer transaction at adevice on one communication channel 110 to experience the same directedmarketing that the consumer experiences on other communication channels110 while interacting with the device. This is achieved by unifyingdisparate transaction processing, distribution mechanisms, and backendsystems for the devices associated with the channels 110A-110H through aunified interface 120 (this can be achieved via a proxy redirection forthe channels 110 to the unified interface 120 while the consumertransacts on the devices). The unified interface 120 has access to avariety of backend systems 125-175 of interest to partnering vendors orsuppliers. Moreover, profiles for the consumer can be federated andprovided in a normalized format to the vendors or suppliers through thevendor/supplier interface 180. So, the customer (the terms “customer”and “consumer” are used interchangeably herein) experiences a unifiedview of vendor or supplier offerings (regardless of the channelcommunications used by the customer to transact), and the vendor orsupplier can manage, analyze, and reach its customers through a commonvendor/supplier interface 180 (which may also be available acrossmultiple channels and devices, such as via a browser-based interface).

As used herein, a “profile” includes a variety of information tied to aconsumer. Some of this information includes, by way of example only,transaction history (electronic, phone, and/or in-person), contacthistory (electronic, phone, and/or in-person interactions noted by anenterprise when occurring with the consumer), complaints noted by theconsumer (electronic, phone, and/or in-person), electronic searchhistory, websites or services accessed by the consumer (electronic,phone, and/or in-person), preferences recorded by the consumer forvarious websites or services (electronic, phone, and/or in-person), andthe like and regardless of the backend systems 125-175 the data wascollected and stored on.

According to an embodiment, customer profiles can be maintained asbeing: specific customer profiles for a subscribing vendor or supplier,specific to selective groups of subscribing vendors or suppliers, orfederated as a single profile across all subscribing vendors or suppliesfor each customer. Still further, and if desired, a profile can beprovided for a single channel 110 or sets of channels 110 for any givencustomer.

The architecture 100 is now discussed in greater detail along with itscomponents in view of the discussion above. It is to be noted that themethods and system presented herein are not just limited to travel andhospitality solutions; that is, any industry can benefit from theunified channel management mechanisms discussed herein

The architecture 100 includes communication channels 110, a unifiedinterface 120, transaction system 125, a marketing system 130, a paymentsystem 140, an analytics system 150, a loyalty system 160, an inventorymanagement system 170, a distribution system 175, and a vendor/supplierinterface 180. The channels 110 include channels tied to communicationsassociated with: email 110A, Web-based activity (services over theInternet) 1108, a gaming device 110C, a Point-of-Service (POS) device110D (Self-Service, Cashier manned, kiosk, etc.), a mobile device 110E,call centers 110F, digital signs 110G, and Television 110H.

The channels 110 represent transactions and/or actions that any givenconsumer may engage in using a variety of devices. For example, theconsumer may engage in email communications associated with a known(registered or used) email 110A for the consumer. The consumer may alsohave browser-based access to a variety of network services, which areassociated with web applications 1108. The web applications 1108 may, insome instances, include cookies, stored local to a processing device ofthe consumer, or stored remotely in a profile associated with the webapplications 1108. The consumer can be engaged in game play or wagering,via gaming devices 110C. Moreover, when the consumer interacts with aPOS device 110D (Self-Service Terminal (SST), cashier-assisted terminal,kiosk, any transaction device capable of receiving marketing informationand transacting in a purchase for a good or a service (note this canrepresent some of the devices already described in channels 110), etc.),the consumer may enter data (such as a loyalty card or credit card) thatpermits capturing and recording profile data associated with theconsumer. The consumer may also use mobile devices 110E (phones,laptops, tablets, wearable processing devices, etc.) to access some webapplications 1108 or to access mobile applications associated withservices (Delta®, Hertz®, Hilton®, and others). The consumer can also,from time-to-time, call a call center 110F of a particular enterprisefor purchases, support, complaints, etc. These interactions with callcenters 110F are stored in profiles. In some case, the consumer mayinteract with digital signage 110G to conduct a transaction through anyother channel 110. Still further, the consumers may conduct transactionswhile viewing television 110H based on relevant advertising offered.

The unified interface 120 is referenced during a consumer transaction bysubscribing vendors of the services of the unified interface 120authorizing a redirection from their existing interfaces associated withthe channels 110 to the unified interface 120. This can also be donetransparently, such as via a proxy configuration where communicationsfrom the channels 110 and to the channels 100 are directed to theunified interface 120.

The unified interface 120 can receive a variety of information(transaction details) for any given customer transaction occurring fromthe channels. The transaction details can include, by way of exampleonly, customer identifying information (loyalty number, registeredemail, registered phone number, address, name, etc.), session identifierfor the transaction initiated by the consumer over one of the channels110, device identifier for the device being used or being used on behalfof the consumer, device location, enterprise identifier associated withthe device, enterprise identifier associated with the transaction, stateof the transaction (start, product selection, payment, receipt, etc.),security level associated with the transaction and/or consumer, and/orperhaps, other configured data.

The transaction details permit the unified interface 120 to perform avariety of actions. (It is noted that multiple sub-transactions can berequired during a single transaction for a consumer by the unifiedinterface 120.) There may also be multiple interactions back and forthbetween an Application Programming Interface (API) that permitscommunications to be delivered and processed between an interfaceoperating on a channel device used by or used on behalf of the consumerand the unified interface 120.

For example, at a start of a transaction, the transaction details areredirected to the unified interface 120. The customer identifyinginformation is extracted to access the loyalty system 160 and acquire athen-existing profile for the consumer. Policy conditions can beserviced from the consumer's loyalty profile and/or policies tied to anidentity of the channel device being used, an identity of an enterprisetied to the interface being used for the transaction (e.g., travel,food, etc.), policies tied to the physical location of the channeldevice, policy conditions tied to a time of day, day of the week, and/orthe calendar day, policy conditions tied to licensing agreements withthe vendors/suppliers, and others. The policy conditions are dynamicallyevaluated to select an appropriate system 125-175 and actions to performagainst those selected systems 125-175, such as, by way of example only,delivering a targeted and relevant (context and/or location relevant)advertisement (available from the marketing system 130) from a selectedvendor with a vendor-permitted offer during the transaction beingperformed by the consumer at the channel device, the format of thepresented advertisement customizable by the selected vendor, via thevendor/supplier interface 180.

Assuming, the consumer clicks or accepts the advertisement from thechannel device, the unified interface 120 can reserve the associatedproduct or service and/or cause delivery of the product or service viainteractions with the inventory management system 170 and thedistribution system 175. Payment processing for the good or service isinitiated via the transaction system 125 and/or the payment system 140(can be externally serviced through one or more transaction/paymentgateways). In an embodiment, the transaction system 125 and the paymentsystem 140 are subsumed into one logical system. Moreover, during thewhole of the transaction, metrics are gathered and housed by the unifiedinterface 120 via the analytics system (the other systems assisting infacilitating transaction processing for the transaction can also recordmetrics in the analytics system 150—such as the transaction system 125,the payment system 140, etc.). It is noted that underlying the metricsand data relied on by each of the systems 125-175 (to varying degrees)can reside in one or more data warehouses (not shown in the FIG. 1 ).

The transaction system 125 can include a variety of internally andexternally managed transaction engines that are integrated and appear tobe a single transaction system 125. The transaction system 125 receivesselective transaction details from the unified interface 120 for anygiven consumer transaction. The components of the transaction system 125permit such things as identification of payment methods (loyalty card,credit card, debit card, coupon discount, gift card, bank account,etc.), computation of total price for the transaction (tax and/or anydiscounts applied), selection of a payment system 140, identification ofa servicing vendor for any goods or services tied to the transaction,and the like.

The marketing system 130 can include a variety of managed sub systemsthat are managed and integrated as one logical marketing system 130.Each sub system capable of being defined via automated (API calls fromprocessing applications) or manual (vendor/supplier interface 180)interfaces. Each sub system, via the automated or manual interface,capable of initiating marketing activity and tracking results. Stillfurther, some of the actions associated with the sub systems can rely oninformation and services available in the analytics system 150, theloyalty system 160, and the inventory management system 170. In somecases, a specific marketing campaign can be a vendor defined survey thatcan be served to the consumer on the channel device or via a differentchannel (defined by the vendor using the automated or manualinterfaces).

In an embodiment, the marketing system 130 includes at least one subsystem that directs target advertisements to a consumer during atransaction based on context of: what the consumer is doing (consumeractivity on the channel device (searches by the consumer, questionsbeing asked by the consumer of an associate operating the channeldevice, etc.), an itinerary known for a consumer (when the consumer isknown to be traveling), and/or a resolved geographical location for alocation of the channel device being operated by the consumer. So, thecontext can be situational based and/or location based. This permitsrelevant marketing to the consumer within a context (situational and/orlocation) that is most likely to benefit the consumer and generate asale by a partnering vendor of the unified interface 120. For exampleconsider a consumer having a mobile phone (mobile device 110E) that isknown to be traveling (such as based on an airline check-in) to a knownlocation (destination of the air travel available from the airlinereservation and flight number of check-in). When that consumer arrivesat a departure gate for his/her flight, the marketing system 125 canreceive an event (raised by location based devices or specifictransactions occurring (i.e., the airport staff scanning the consumer'sboarding pass)), which indicates to the marketing system 125 that theconsumer post security or at the gate ready to board the aircraft. Themarketing system 125, via the unified interface 120, can then pushadvertisements for purchasing vendor services and products that arerelevant to the consumer's flight, destination, or supporting services,such as alcohol or food purchase, Internet access, movie orentertainment download, car or rail transportation, accommodations, orcity tour, etc. The consumer then selects a particular good or serviceand the unified interface 120 processes it through the various systems125-175 (transparent to the consumer on the mobile device 110E). As aresult of the purchase, the unified interface 120 delivers an electronicreceipt of the transaction via a Quick Response (QR) code or bar code tothe interface of the mobile device 110E. That electronic receipt can bescanned by the airline staff to confirm payment of the good or service.It may also be that a link is delivered, which permits a download of anentertainment selection to the mobile device 110E (or a code used forInternet access). In some cases, the consumer may need to take no actionbecause the unified interface 120 transmits the confirmation of what waspurchased to devices that are controlled by the airline staff orsupplier along with a profile data for the consumer, such that theairline staff or supplier can deliver the appropriate good or service tothe consumer. This is but one of many possible scenarios where themarketing system 125 is capable of delivering situational and/orlocation relevant marketing to the consumer when it would benefit thatconsumer and a vendor associated with a good or service.

The payment system 140 includes a variety of externally accessiblepayment gateways, supporting online and offline processing. Each paymentgateway driven by the policy conditions discussed above for any giventransaction. In some cases, the payment system 140 is activated by thetransaction system 125 for purposes of confirming payment of atransaction from a consumer. In fact, the transaction system 125 inhandling a transaction can select or identify for the payment system 140the payment gateway that is to be used to complete the paymentprocessing.

The analytics system 150 has access to the data warehouses for retrievalof data to perform mining and reporting. The mining activity may berelated to marketing campaigns initiated by the marketing system 125.Moreover, the analytics system 150 may access one or more sub, andperhaps, external analytics systems 150 via API calls provided anddefined by vendors or suppliers via automated (application processingusing API calls to interface) or manual (vendor/supplier interface 180).This provides a holistic view of the consumer's transactions, spendinghabits, and value.

The loyalty system 160 can include a variety of sub loyalty systemsdefined by the vendors or suppliers via the automated (API calls fromprocessing applications) or manual (vendor/supplier interface 180)interfaces. Moreover, in an embodiment, the loyalty system 160 includesa hierarchy of sub systems that includes a root hierarchy that ties orlinks a customer to all loyalty sub systems. Each level of the hierarchybelow the root can represent one or more groupings of the sub systems.In this way, a profile of a customer for classes, groups, or industriescan be defined. The level of access to the hierarchy that a subscribingvendor or supplier has can be dictated by policy conditions as well,such as subscription level of the vendor or supplier, and the like. Eachcustomer loyalty record (can be many at various levels of the hierarchyas well as varying degrees of federated records at higher levels of thehierarchy) is associated with a customer profile (the details of whichwere previously discussed above). Moreover, some fields of each recordcan link to the analytics system 150 for dynamic calculation orresolution when a particular profile of a customer is served for atransaction (such as last activity noted and channel activity occurredon or a total number of activities for a particular product or serviceduring a given time period).

The inventory management system 170 can include a variety of subinventory management systems defined by each of the vendors or suppliersusing the vendor/supplier interface 180. Some of these sub systems mayalso be external and accessed via API calls defined by the vendors orsuppliers.

The distribution system 175 can include a variety of sub distributionsystems defined by each of the vendors or suppliers using thevendor/supplier interface 180. The distribution system 175 permitsscheduling and/or planning of needed resources for delivering goods orservices to consumers performing transactions via the channels 110.

The vendor/supplier interface 180 presents an interface for vendors andsuppliers that subscribe to the architecture for accessing the systems125-175. In some cases, the interface is used to provide access anddefine API calls that the unified interface 120 is to use to accessvendor/supplier-specific systems 125-175. This provides integration withwhat vendors and suppliers are already using. The interface 180 alsopermits vendor/supplier-specific policy conditions, marketing actions,payment options, and notifications.

The architecture 100 permits vendors/suppliers to maintain a consistentexperience for the customers that they service across multiple disparatechannels 110, and the architecture 100 permits delivery of situationaland/or location relevant targeted advertisements to the consumers overthose channels 110. Transactions can also be monitored and processed onbehalf of the vendors or suppliers. Still further, any subscribingvendor or supplier to the architecture can reach customers in channels110 that they previously may not have been able to reach and have accessin those channels 110 to customer profiles for taking marketing actions(including situational and location-based context marketing actions).

It is noted that a variety of operating scenarios are possible and theabove-noted unified channel management examples were presented toillustrate the power of one technique of the invention and was notintended to limit other operating scenarios achievable with thetechniques presented herein.

Some of the above-noted aspects of the invention and other aspects arenow presented and discussed with reference to the FIGS. 2-4 .

FIG. 2 is a diagram of a method 200 for unified channel management,according to an example embodiment. The software module(s) thatimplements the method 200 is referred to as a “channel transactionmanager.” The channel transaction manager is implemented as executableinstructions programmed and residing within memory and/or anon-transitory computer-readable (processor-readable) storage medium andexecuted by one or more processors of a device. The processors of thedevice that executes the channel transaction manager are specificallyconfigured and programmed to process the channel transaction manager.The channel transaction manager has access to one or more networksduring its processing. The networks can be wired, wireless, or acombination of wired and wireless.

In an embodiment, the channel transaction manager is the unifiedinterface 120 of the FIG. 1 .

According to an embodiment, the device that executes the softwaremodule(s) representing the channel transaction manager is a proxyserver. In an embodiment, the proxy server is a transparent proxy. In anembodiment, the proxy server is a forward proxy.

At 210, the channel transaction manager identifies a transactionoccurring over a communication channel (any of the communicationchannels 110 from the FIG. 1 ).

According to an embodiment, at 211, the channel transaction managerreceives transaction details from a POS device (POS 110D of the FIG. 1 )that a consumer is accessing during the transaction. The transactiondetails can include a variety of information, such as consumeridentifying information (loyalty account number, payment card number,vendor tied to the loyalty account number, registered email address,registered phone number, name, address, and the like). It is noted thatthe transaction details can include a variety of other usefulinformation, such as one or more of: POS device identifier, time of day,day of week, calendar day, vendor identification supply goods orservices relevant to the transaction, pricing information for the goodsor services, available discounts, transaction communication sessionidentifier, versioning information for the POS interface being accessedby the consumer for the transaction, and other information. The consumeridentifying information permits the channel transaction manager tolocate profiling data (can also be referred to as a “profile” herein)for the consumer. As stated above with reference to the discussion ofthe FIG. 1 , the consumer can have multiple hierarchical profiles thatspan vendors and/or channels and each profile can include data discussedin the FIG. 1 .

In an embodiment of 211, the trigger from the POS device (POS 110D) canoccur from a beacon device or other form of transmitter that caninitiate the interaction with a consumer. This can occur through or incooperation with any channel 110.

It is also to be noted that a consumer can remain anonymous duringtransaction processing. This can be done when there is no availableconsumer identifying information or where the consumer by priorinstructions wishes to remain anonymous. Moreover, a profile for ananonymous consumer can still be developed and derived based onevaluation of policy conditions associated with, perhaps, the time ofday, day of week, calendar day, transaction type, goods or servicepurchased, POS device, channel used, and the like.

At 220, the channel transaction manager federates or aggregates aprofile for a consumer associated with the transaction. Again, thatconsumer may be an “anonymous consumer” in some embodiments. Forexample, the loyalty system 160 of the FIG. 1 is queried using consumeridentifying information (or an anonymous consumer identifier) to returnone or more profiles to be associated with the consumer (the loyaltysystem 160 can include a variety of sub loyalty systems (some of whichmay be vendor-specific) as discussed in the FIG. 1 ).

According to an embodiment, at 221, the channel transaction managernormalizes sub profiles associated with the consumer for the at leastone other channel into an aggregated profile representing the federatedprofile. This can include multiple channels, each of which can bedisparate from the others. By normalizing, it is meant the channeltransaction manager transforms the sub profiles into a proper processingand evaluation format that the channel transaction manager cangenerically handle, since some of the sub profiles may have been derivedfrom disparate sub loyalty systems.

In an embodiment, at 222, the channel transaction manager aggregatesmultiple profiles associated with the consumer as the federated profile.Each profile is associated with a different vendor loyalty account ofthe consumer. The processing associated with such an aggregation wasdiscussed herein and above.

At 230, the channel transaction manager delivers an advertisement duringthe transaction based on evaluation of the federated profile. In anembodiment, the advertisement is delivered from a marketing system 130based on a relevant situational context of the consumer transactionand/or a location resolved for the consumer during the transaction(advertisement context and location-based). It is noted that theselection and delivery of the advertisement can also be based on otherconditions defined outside the federated profile. These conditions areconfigurable parameters and dynamic in nature and can come for a varietyof sources, such as an enterprise distributing the channel transactionmanager as a service, a vendor associated with the POS device being usedfor the transaction, vendors associated with available advertisements,channel service providers, resolved location for the consumer, anitinerary known for the consumer, and/or other sources. The mechanismfor selection can be configured based on conditions defined for thesources and at least a portion of the federated profile.

For example, and an embodiment at 231, the channel transaction managerdetermines the advertisement in response to evaluation of at least onepolicy condition associated with one or more of: the federated profile,an identity of the consumer (can be an anonymous identity in somesituations), an identifier for the channel being used for thetransaction, a physical location of a POS device being used for thetransaction (location-based context), and an itinerary for the consumerduring travel, and conditions defined in one or more vendor agreementsassociated with the advertisement.

According to an embodiment, at 232, the channel transaction managerobtains the advertisement from marketing system that is at leastpartially defined by a vendor associated with the advertisement. Forexample, a sub marketing system of the marketing system 130 defined bythe vendor using the vendor/supplier interface 180 of the FIG. 1 . Thesub marketing system can be provided in an automated fashion as well viathe interface 180, such as by defining or supplying schema definitionsand API calls used in accessing and managing the sub marketing system.It is also noted that the marketing system 180 may provide genericmarketing schemas, operations, and APIs accessible for the vendor toestablish and maintain via the interface 180.

In an embodiment, at 240, the channel transaction manager facilitatesthe processing of the transaction over the channel being used for thetransaction. This can entail accessing a variety of systems, such as thetransaction system 125 and/or the payment system 140 (perhaps throughgateways to employ external payment mechanisms), the marketing system130 (perhaps to apply a discount or an offer related to thetransaction), the analytics system 150 (perhaps to record metrics,initiate automatic notifications based on the metrics, initiate reportsbased on the metrics, etc.), the loyalty system 160 (perhaps to creditor debit one or more loyalty accounts of the consumer), the inventorymanagement system 170 (perhaps to debit inventory, initiate an inventoryreplenishment order based on the purchase of the good or service, andthe like), and the distribution system 175 (perhaps to initiate deliveryof a good or service for the transaction, order and/or schedule the goodor service, and the like).

In an embodiment, at 250, the channel transaction manager capturesmetrics for the transaction and the consumer during the transaction. Themetrics can be housed via the analytics system 150 and/or directly orindirectly through a data warehouse, which may then trigger automatedactions in the analytics system 150. It is also noted that the metricscan be captured for any entity or resource associated with thetransaction; for example, the supplier of a good or service relevant tothe transaction, a supplier of the POS device involved in thetransaction. The analytics system 150 is capable of rolling up metricsfor classes of transactions, industries, customers, or anyvendor-defined roll-up acquired through the interface 180.

One now appreciates how a vendor can achieve multi-channel consistency(similar format, similar interface, similar advertisement andtransactional items, etc.) with its customers to market (situational andlocation-based context) and manage its customer relationships throughthe processing capabilities of the channel transaction manager. Thisprovides consistency and provides vendors with access to channelcommunications that they may never have had access to in the pastbecause of vendor expense and/or vendor technology deficiencies andprovides an opportunity to provide the consumer with marketing that isof benefit to the consumer at a relevant time and place when thatmarketing is received by the consumer, which makes a sale by a vendormore likely to occur and which satisfies a consumer and makes thatconsumer a return and loyal consumer to the vendor.

FIG. 3 is a diagram of another method 300 for unified channelmanagement, according to an example embodiment. The software module(s)that implements the method 300 is referred to as a “vendor interfacemanager.” The vendor interface manager is implemented as executableinstructions programmed and residing within memory and/or anon-transitory computer-readable (processor-readable) storage medium andexecuted by one or more processors of a device. The processors of thedevice that executes the vendor interface manager are specificallyconfigured and programmed to process the vendor interface manager. Thevendor interface manager has access to one or more networks during itsprocessing. The networks can be wired, wireless, or a combination ofwired and wireless.

In an embodiment, vendor interface manager is the vendor/supplierinterface 180 of the FIG. 1 .

The vendor interface manager includes processing directed to automatedactions and semi-automated actions acquired through a vendor-facinginterface.

In an embodiment, the vendor interface manager's vendor-facing interfaceis a browser-based interface accessible via a network connection andresides on a server that processes the vendor interface manager. In anembodiment, some or all portions of the vendor-facing interface canprocess on a POS device as an application that interacts with otheraspects of the vendor interface manager on a server. In an embodiment,the vendor interface manager includes some processing available tovendors through automated applications as API calls.

At 310, vendor interface manager obtains a first set of actions toperform on a first channel. Again, the first channel can be any of thechannels 110 depicted in the FIG. 1 . In an embodiment, the first set ofactions includes a set of 1 action. In an embodiment, the first set ofactions includes a plurality of actions.

In an embodiment, at 311, the vendor interface manager automaticallyinterfaces at least some of the first set of actions to at least oneexternal system associated with a vendor. This was discussed above withrespect to the FIG. 1 . This can be achieved via automated API callsbetween systems 125-175 and corresponding external subsystems relatedthereto. Input parameters and output data provided and returned in theAPI calls can be defined via schema definitions.

According to an embodiment, at 312, the vendor interface managerinteracts with a vendor using a Graphical User Interface (GUI) to definethe first actions, such as a browser-based vendor-facing interface. Thisprovides automated common access to the vendor from a variety ofplatforms and devices having access to the Internet.

At 320, the vendor interface manager links the first set of actions toat least one second channel. That is, the actions are made available foroperation on one or more second and disparate channels from that whichwas associated with the first channel. This may entail normalizing thefirst set of actions into a generic processing format and thentranslating from the generic processing format to format expected byeach of the one or more second and disparate channels.

In an embodiment, at 321, the vendor interface manager provides thelinking when the vendor lacks automated access to the one or more secondchannels. This is a situation where the vendor lacks the ability toreach a consumer on the second channels and uses the vendor interfacemanager to achieve channel integration with each channel that theconsumer is detected as using.

At 330, the vendor interface manager processes the first set of actionsfor transactions occurring on the first channel and each of the secondchannels. So, for example, advertisement formats and types ofadvertisements that a vendor supplies a consumer over the web 1106 areconsistent when that consumer uses digital signage 110G, a television110H, a gaming device 110C, etc. for transactions.

According to an embodiment, at 340, the vendor interface managerdelivers vendor-defined analytics to a vendor for the transactions. Forexample, the vendor accesses a vendor-facing interface associated withthe vendor interface manager and provides instructions for generatingnotifications and reports based on vendor-defined analysis operationsfor the transactions. It is noted that generic notifications and reportscan also be selected by the vendor via the vendor-facing interface aspublished through the analytics system 150.

In an embodiment, at 350, the vendor interface manager servicesvendor-defined inventory management for the transactions. So, forexample, the vendor uses the vendor-facing interface to define itsinventory data schema, API operations, and policy conditions. Thisvendor-supplied detail can be processed in an automated manner by theinventory-management system 170 to service inventory for the vendor.Again, the inventory management can be generically available and,perhaps, customized to the needs of the vendor (via vendor-suppliedselections through the vendor-facing interface). That is, the actualinventory management can remain vendor controlled and accessed throughthe vendor-facing interface, can be partially controlled through thevendor-facing interface, or entirely controlled through thevendor-facing interface.

According to an embodiment, at 360, the vendor interface manager managesa vendor-defined loyalty system for the transactions. This scenario wasdiscussed herein and above.

FIG. 4 is a diagram of a unified channel management system 400,according to an example embodiment. Various components of the unifiedchannel management system 400 are programmed and reside within memoryand/or a non-transitory computer-readable medium and execute on one ormore processors of one or more devices. The unified channel managementsystem 400 has access and can communicate over one or more networks; andthe networks can be wired, wireless, or a combination of wired andwireless.

The unified channel management system 400 includes a server 401 having atransaction module 402 and an vendor interface module 403 programmedwithin memory and/or a non-transitory computer-readable storage media asexecutable instructions for executing on one or more processors of theserver 401. In an embodiment, the unified channel management system 400also includes a vendor subscription module 403 programmed within memoryand/or a non-transitory computer-readable storage media as executableinstructions for executing on one or more processors of the server 401.Each of these components of the system 400 is now discussed in turn.

The server 401 includes one or more processors, memory, storage, andaccess to multiple networks (wired, wireless, or a combination of wiredand wireless).

In an environment, the server 401 is multiple devices logicallyassembled as cloud processing environment (cloud).

The transaction module 402 is operable to execute as executableinstructions, residing in a non-transitory computer-readable storagemedium, on the server 401. Further, the transaction module 402 isoperable (configured) to process or facilitate in the processing ofmulti-channel transactions occurring on POS devices. This was discussedabove with reference to the FIGS. 1-3 . Additionally, the transactionmodule 402 is operable to deliver consistent vendor-suppliedadvertisements during the multi-channel transactions to consumers ofvendors. Again, this was discussed above with reference to the FIGS. 1-3.

In an embodiment, the transaction module 402 is the unified interface120 described above with reference to the FIG. 1 .

In an embodiment, the transaction module 402 is the transaction channelmanager described above with reference to the FIG. 2 .

According to an embodiment, the transaction module 402 is furtheroperable (configured) to federate profiles for consumers across multiplechannels. The federated profiles evaluated to at least partiallydetermine the vendor-supplied advertisements (discussed above withreference to the FIGS. 1-2 ).

The vendor interface module 403 is operable to, at least partially,execute as executable instructions, residing in a non-transitorycomputer-readable storage medium, on the server 401. In an embodiment,at least some of the executable instructions for the vendor interfacemodule 403 execute on a POS device.

The vendor interface module 403 is further operable to receivevendor-defined actions where at least one of those actions is relevantto determining the vendor-supplied advertisements during themulti-channel transactions (discussed above in the FIGS. 1 and 3 ).

In an embodiment, the vendor interface module 403 is the vendor/supplierinterface 180 of the FIG. 1 .

In an embodiment, the vendor interface module 403 is the vendorinterface manager described above with reference to the FIG. 3 .

According to an embodiment, the vendor interface module 403 is furtheroperable to interface at least some of the vendor-defined actions toexternal systems associated with the vendor (discussed above in theFIGS. 1-3 ).

In an embodiment, the system 400 also includes a vendor subscriptionmodule 403 that is operable to execute as executable instructions,residing in a non-transitory computer-readable storage medium, on theserver 401. The vendor subscription module 403 is also operable tomanage subscriptions of vendors having access to the vendor interfacemodule 402. The subscriptions can be of varying configured levels ofaccess and security depending on conditions and pricing defined in thesubscriptions.

It should be appreciated that where software is described in aparticular form (such as a component or module) this is merely to aidunderstanding and is not intended to limit how software that implementsthose functions may be architected or structured. For example, modules120 and 130 are illustrated as separate modules, but may be implementedas homogenous code, as individual components, some, but not all of thesemodules may be combined, or the functions may be implemented in softwarestructured in any other convenient manner.

Furthermore, although the software modules are illustrated as executingon one piece of hardware, the software may be distributed over multipleprocessors or in any other convenient manner.

The above description is illustrative, and not restrictive. Many otherembodiments will be apparent to those of skill in the art upon reviewingthe above description. The scope of embodiments should therefore bedetermined with reference to the appended claims, along with the fullscope of equivalents to which such claims are entitled.

In the foregoing description of the embodiments, various features aregrouped together in a single embodiment for the purpose of streamliningthe disclosure. This method of disclosure is not to be interpreted asreflecting that the claimed embodiments have more features than areexpressly recited in each claim. Rather, as the following claimsreflect, inventive subject matter lies in less than all features of asingle disclosed embodiment. Thus the following claims are herebyincorporated into the Description of the Embodiments, with each claimstanding on its own as a separate exemplary embodiment.

1. (canceled)
 2. A method, comprising: redirecting, by a processor,details for a transaction or actions being performed by a user from afirst channel to a second channel while the transaction or actionscontinue to be processed on the first channel; generating, by theprocessor, a context associated with the user and the transaction oractions using the details; selecting, by the processor, a backend systemfrom a plurality of backend systems based on the context and anaggregated profile associated with the user; and linking, by theprocessor, the backend system to the first channel and the user'stransaction or the user's actions over the second channel.
 3. The methodof claim 2, wherein generating further includes obtaining from thedetails a location of the user and an activity that the user is engagedin over the first channel and generating the context based on thelocation and the activity.
 4. The method of claim 3, wherein generatingfurther includes identifying the details as being associated with atransaction activity of the user who is engaged in the transaction onthe first channel, obtaining a state of the transaction and transactiondetails for the transaction, and generating the context based on thestate, the transaction details, the transaction activity, the location,and the first channel.
 5. The method of claim 3, wherein generatingfurther includes identifying the details as being associated with aweb-based activity of the user who is performing the actions over abrowser-based interface, obtaining from the details a website associatedwith the browser-based interface and searches performed by the user onthe website, and generating the context based on the website, thesearches, the location, and the first channel.
 6. The method of claim 3,wherein generating further includes identifying the details as beingassociated with a call center activity of the user who is performing theactions over a voice call, obtaining from the details the call center,and generating the context based on the call center, the location, andthe first channel.
 7. The method of claim 2 further comprising,maintaining, by the processor, metrics associated with a session betweenthe backend system and the user after the linking.
 8. The method ofclaim 2, wherein redirecting further includes transparently redirectingthe details from the first channel to the second channel.
 9. The methodof claim 2, wherein linking further includes providing a unifiedinterface to the backend system of the second channel and the user onthe first channel to interact in a session during an activity of theuser associated the transaction or the actions.
 10. The method of claim9, wherein providing further includes processing an order placed by theuser through the unified interface with the backend system during thesession.
 11. The method of claim 10, wherein processing further includesprocessing a payment made by the user for the order through the unifiedinterface with the backend system during the session.
 12. The method ofclaim 10, wherein processing further includes processing a payment madeby the user for the order through the unified interface with an externalpayment system associated with the backend system during the session.13. A method, comprising: maintaining, by a processor, an aggregatedprofile for a user for activities that the user has engaged in over aplurality of channels; identifying, by the processor, an activity of theuser is currently engaged in over a first channel; obtaining, by theprocessor, activity details for the activity; generating, by theprocessor, a context for the activity based on the activity details;selecting, by the processor, a backend system based on the activity andthe activity details; and linking, by the processor, the backend systemfrom a second channel associated with the backend system to the activityand the user on the first channel.
 14. The method of claim 13, whereinidentifying further includes identifying the activity as a transactionbeing processed on a terminal or on a user device.
 15. The method ofclaim 13, wherein identifying further includes identifying the activityas a website that the user is browsing through a browser of a userdevice.
 16. The method of claim 13, wherein identifying further includesidentifying the activity as a game being played by the user via a gamingdevice or a user device.
 17. The method of claim 13, wherein identifyingfurther includes identifying the activity as being associated with theuser watching television.
 18. The method of claim 13, whereinidentifying further includes identifying the activity as beingassociated with the user engaged with a call center.
 19. The method ofclaim 13, wherein linking further includes proxying a session betweenthe user on the first channel and the backend system on the secondchannel during the activity of the user on the first channel.
 20. Asystem, comprising: a first device associated with an activity of theuser on a first channel; a second device associated with a backendsystem on a second channel; and a server that comprises a processorconfigured to perform operations comprising: identifying the activity ofthe user on the first device over the first channel; generating acontext for the activity of the user based on details associated withthe activity on the first channel; selecting the backend system from aplurality of backend systems based on the context and an aggregatedprofile maintained for the user for other activities of the user overthe first channel and third channels; and proxying a session between thebackend system on the second channel and the user on the first channelduring the activity of the user on the first channel.
 21. The system ofclaim 20, wherein the first device is a self-service terminal or apoint-of-sale terminal and the activity is a transaction that the useris currently engaged in.